package com.mego.thought.G_02_object;

/**
 * 思考的一个问题：
 * 面向对象相比面向过程有哪些优势？面向过程真的就过时了吗？
 *
 * 问题的场景：
 * 在我们实际开发的过程中，一开始我们接到的任务都是比较简单的。然后随着项目的落地运营，客户会根据自己的需要，来提出不同的需求。从而使我们流程不再
 * 像当初的只有一条主线流程，随着业务的不断发展，整个程序的处理流程画出来的话，会是一个网状结构。
 * 面对这种情况，这个时候，如果我们还使用面向过程编程这种流程化、线性的思维方式，去翻译这个网状结构，去思考如何把这个程序拆解为一组顺序执行的方法，
 * 就会比较吃力。（这个时候，面向对象的编程风格的优势就比较明显了。）
 *
 * 如何去使用面向编程来解决这个问题呢？
 * 我有一个疑问：就是面向对象编程，它是以类为思考的对象。在进行面向对象编程的时候，我们一上来并不是就去思考，如何将复杂的流程拆解为一个一个方法，而
 * 是采用曲线救国的策略，先去思考如何给业务建模型，如何将需求翻译为类，如何给类之间建立交互关系，而完成这些工作完全不需要考虑错综复杂的处理流程。
 * 当我们有了类的设计之后，然后再像搭积木一样，安装处理流程，将类组装起来形成整个程序。（这种开发模式、思考问题的方式，能让我们在应对复杂程序开发
 * 的时候，思路更加清晰）
 *
 * 我碰到的问题是：
 * 就算是面向对象编程，不也是要在主流程中加if判断来向不同分支开展出去的吗？
 *
 *
 */
public class G_02_01_main {
    /**
     * 一些案例：
     * OOP 更能应付复杂流程的程序开发，自己是深有体会。
     *
     * 去年做了一个功能，第一版着急上线，就照着流程图翻译，最后就是一组顺序执行的方法集。if 分支特别多。
     *
     * 上线后有空，自己重构了一版。这次是翻译了泳道图：data_provider、rule_filter_chain、data_consumer 和 data_writer。
     * data_provider 提供 3 种类型的数据。每种类型数据有 2 种规则。匹配规则后，会有一些数据处理，如与订单绑定、返佣记录等。最后是将这些数据持
     * 久化到数据库。处理过程还使用了多态特性，因此在调用 rule_filter_chain、data_consumer、data_writer 处的代码都特别精简，都是从 Map
     * 获取处理对象，然后直接调用方法。
     *
     * 现在回看，重构时自己关注最多也是思考最多的是每个阶段的类对象，它的职责是什么。如入参是什么，业务逻辑处理，处理后的出参是什么。实现完这些类
     * 后，就真的是像搭积木一样将这些类串起来就可以了。就跟文章说的一样：业务建模、翻译需求为类、类之间交互。
     *
     * 重构后的代码逻辑清晰了，也更简洁了。整个业务也更容易理解了。但是有一点，重构之后，类文件也增加了挺多。但是相比一个类几百上千行代码，
     * 我更喜欢简短的类。适当的增加一些类文件，也是能接受的。
     */
}
